Authentication, authorization and accounting (AAA) functions refer to the functions of processing authentication, authorization and accounting of subscribers. AAA functions are often required when a subscriber wants to receive a predetermined service through a network. One technique discussed in the related art for providing AAA functions is through a remote access dial-in user service (RADIUS) protocol. However, the RADIUS protocol suffers from many disadvantages including scalability, supporting a large number of subscribers that each require server-based authentication, and lack of ability to fulfill the requirements of new technologies, such as wireless networks, mobile internet protocols (IPs) and the others.
To overcome these disadvantages, another type of AAA protocol, known as a Diameter protocol, has been defined. The Diameter protocol is an extensible peer-based AAA protocol that provides AAA functions for conventional technologies as well as new technologies. The Diameter is designed as a peer-to-peer architecture, where every network node that implements the Diameter protocol can act as either a client or a server depending on the network deployment.
The deployment of a typical Diameter protocol is illustrated in FIG. 1. Diameter messages are exchanged between a Diameter client 110 and a Diameter server 120. The Diameter client 110 is a device at the edge of the network that performs access control including, for example, a network access server (NAS) or a foreign agent (FA). The Diameter client 110 generates Diameter requests for authentication, authorization, and/or accounting of subscribers. The Diameter server 120 performs authentication and/or authorization of subscribers according to requests generated by the Diameter client 110.
In order to allow communication between the Diameter client 110 and server 120, a connection is first established between them, where the client and server are exchanging capabilities. Then the client and server communicate through messages; these messages may be part of multi-message sessions. A Diameter message is the base unit for sending a command or delivering a notification to other Diameter nodes. For differing purposes, the Diameter protocol has defined several types of Diameter messages, which are identified by their command code. For example, a Diameter connection is typically established by exchanging Capability-Exchange-Request (CER) and Capabilities-Exchanging-Answer (CEA) messages between the client 110 and server 120. To close a Diameter connection, the client 110 and server 120 exchange disconnection messages, such as a Disconnect-Peer-Request (DPR). Generally, Diameter messages sent by the Diameter client 210 are “request messages” and Diameter messages sent by the Diameter server 220 are “answer messages”.
Generally, a session is a logical connection between two Diameter nodes and refers to the interactions between a Diameter client 110 and a Diameter server 120 in a given period of time. A session is associated with a client-generated session identification (ID) number that is globally and eternally unique. The session-ID is used to identify a particular session during further communication. The Diameter client 110 and server 120 communicate over a transport protocol, such as a transmission control protocol (TCP) or a stream control transmission protocol (SCTP).
The Diameter protocol is not bound to a specific application that can utilize the protocol, but rather provides a platform for message exchanging features. For example, as the authentication and authorization mechanisms vary among applications, the Diameter protocol does not define command codes for authentication and authorization purposes. In contrast, the behavior and message to be exchanged for accounting are clearly defined. Accounting as defined in the Diameter protocol requires the device that generates accounting records to follow the direction of an authorization server. In addition, unlike authentication and authorization, accounting applications are not real-time applications. That is, an authorization request should be served immediately, but that may not be the case for an accounting request generated by a billing server.
As network providers continue to increase their services, reliability, scalability and availability become increasingly important. High availability solutions are required to enable subscribers to use the network services and to bill subscribers for using such services during peak-load periods or during device maintenance or failure. Currently, network providers try to meet growing demand for AAA services, and Diameter services in particular, by adding more hardware in the form of Diameter servers and network devices. However, this is an inefficient and costly approach.
That is, there is a need for an efficient solution that enables the continued and reliable operating of Diameter services and functions even during peak-load periods, device maintenance, or device failures.